home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / July 96 / Re Assert messages.2 < prev    next >
Encoding:
Internet Message Format  |  1996-07-03  |  3.0 KB  |  [TEXT/ttxt]
  1. Subject:     Re: Assert messages
  2. Sent:        7/3/96 3:37 PM
  3. Received:    7/3/96 2:51 PM
  4. From:        Greg Friedman, friedman@cognosis.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. Karl Jepsen wrote:
  9. > More on the assert messages  "Why is an autodestruct object of class
  10. > TryBlockContext being constructed in a bad context? See FWExcImp.cpp for
  11. > possible causes. "  when gif or JPEG graphic files are embedded into
  12. > ODFDraw, ODFContainer, or our part where CyperDog is the viewer:
  13. >
  14. > CyberDog issues an RequestFrameShape call twice.  It is on the 2nd call
  15. > that the assert messages are output. (why the asserts are generated I do
  16. > not know).  Anyway the calling chain for both of these calls are as
  17. > follows:
  18. >
  19. > cyberdog
  20. >   ODFrame::RequestFrameShape
  21. >      ODPartWrapperRequestFrameShape
  22. >         FW_CODPart::RequestFrameShape   <---  this routine causes the asserts
  23. >
  24. > Is this a problem with CyberDog & ODF 1?  What do we need to do to ODFDraw,
  25. > ODFContainer, and our part?
  26.  
  27. I debugged this interaction last night. I didn't want to post a response
  28. until I had a clear idea of what is happening.
  29.  
  30. The CyberDog JPEG part is threaded. At the time of the call to
  31. RequestFrameShape, the JPEG part is executing within a thread. When an ODF
  32. autodestruct object is created, our emulated exception library tries to
  33. determine whether the object being created on the stack, in the heap, or
  34. during static initialization. If the object is on the stack, our exception
  35. subsystem tracks the object so that it can be correctly destructed when an
  36. exception is thrown over its stack frame.
  37.  
  38. The fact that CyberDog is calling us from within an execution thread other
  39. than the process' primary thread is confusing our exception subsystem. We
  40. can tell that our autodestruct objects are not being created at static init
  41. time, and that they aren't in the heap. The problem is that since we are an
  42. alien execution thread, the stack has been swapped out, and are stack-based
  43. object logic isn't working.
  44.  
  45. I consider this an important issue. We will fix it in the next release of ODF.
  46.  
  47. For now, you have two options:
  48.  
  49. 1. Ignore the asserts. I realize this is annoying, but there isn't anything
  50. I can recommend right away.
  51.  
  52. 2. If you are using a compiler that supports native exceptions (e.g.,
  53. CodeWarrior 8 or 9), enable native exceptions. You can use the ODFBuilder
  54. application to do this for the ODF projects. You'll have to do it yourself
  55. for your own project. The problem will not manifest when native exceptions
  56. are used.
  57.  
  58. At some point in the future, The ODF Exception subsystem will go away. Our
  59. emulated exceptions were put in place long before the popular compilers on
  60. the Mac had builtin support for exceptions. The goal was to emulate
  61. exceptions until such time as the compilers we build with implemented real
  62. exception support.
  63.  
  64. Greg Friedman.
  65.  
  66.  
  67. ___________________________________________________________
  68.  Greg Friedman       ODF Engineering        Apple Computer
  69.  
  70.  
  71.